Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000170_owner-urn-ietf _Fri Nov 15 06:20:31 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id GAA03277 for urn-ietf-out; Fri, 15 Nov 1996 06:20:31 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id GAA03272 for <[e-mail]>; Fri, 15 Nov 1996 06:20:28 -0500
Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA26721  (mail destined for [e-mail]); Fri, 15 Nov 96 06:20:21 -0500
Received: from ifi.unizh.ch by josef.ifi.unizh.ch
          id <[e-mail]>; Fri, 15 Nov 1996 12:18:17 +0100
Subject: Re: [URN] Re: I18N does not belong in URNs
To: [e-mail]
Date: Fri, 15 Nov 1996 12:18:16 +0100 (MET)
Cc: [e-mail]
In-Reply-To: <v02130500aeb0fc2678c3@[128.148.157.46]> from "David G. Durand" at Nov 14, 96 12:13:21 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2314
From: Martin J Duerst <[e-mail]>
Message-Id: <"josef.ifi..298:15.10.96.11.18.26"@ifi.unizh.ch>
Sender: [e-mail]
Precedence: bulk
Reply-To: Martin J Duerst <[e-mail]>
Errors-To: [e-mail]

David G. Durand wrote:

[Sorry: In an earlier mail, I attributed a quote to Mark Fischer when
it indeed came from David G. Durand.]

> UTF-8, with
>%encoding for characters over 127, is a unique transcribable byte sequence
>capable of grandfathering all of the namespaces we have discussed. As long
>as we require naming authorities to use well-defined Unicode names, we can
>even handle non-Unicode characters, by making authorities that need them
>define a policy for their application of the private-use area. consistent
>use of private use characters will guarantee uniqueness, so we are all set!

The mentioning of the private-use area tuches the following problems:

- What to do with characters not in ISO 10646/Unicode.
- What to do with namespaces not defined in terms of characters.
- What to do with URNs that are not valid %HH encoded UTF-8 sequences.

As for characters not in Unicode, this is really a case that should appear
extremely rarely. Unicode already contains an enormous amount of characters
from all kinds of international, national, and corporate standards. And
new scripts and characters are still being added. The use of the private
area(s) should definitely not be openly suggested, but be downplayed as
much as possible.

As for namespaces not defined in terms of characters, we can either
require that they define a solution in terms of ISO 10646 characters,
or we can allow them to define their own solution in terms of octets.
For space and other considerations, they ideally will choose something
similar to the data: URL, but we have to clearly specify what we
tolerate and what not.

If we tolerate direct encoding of arbitrary octets with %HH, then we
have to address the issue of URNs where the %HH ecodings do not reperesent
a correct UTF-8 sequence. Mainly for reasons of cross/backwards compatibility
with URLs, I would suggest that we clearly specify that software
transporting, storing, and manipulating URNs should take them as they
are, even if they are not interpretable as UTF-8. In user-friendly
environments, octets that do not form a valid UTF-8 sequence, as well as
UTF-8 combinations that do not represent characters (the Unicode code
position is undefined) or that cannot be displayed (lack of fonts,...)
should be displayed in %HH notation.


Regards,    Martin.